output was handled by the PdfTeX engine
in MKII in 2005. What sort of output did the software produce before
PdfTeX was introduced? Was this the same as the output produced by the
software before the publication of the PDF specification?
2005 is when we started with luatex which is a follow up
Hello,
I was reading about the history of ConTeXt in the Not So Short Introduction
To ConTeXt and I have a historical question. I noticed that the PDF
specification was published in 1993 yet ConTeXt was invented in 1991. The
book suggests that PDF output was handled by the PdfTeX engine in MKII
that is not what you intend.
Since you have TeX Live, I recommend you get the ConTeXt in TeX Live working
first, then decide if you need the latest ConTeXt from the garden.
> On Feb 20, 2024, at 7:21 AM, Pablo Rodriguez via ntg-context
> wrote:
>
> The engine you are using is pdfTeX (from T
too).
Reading your log (which I simply ignored and Gavin took care to read it
[totally my fault]), the first line you get is:
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023)
(preloaded format=pdflatex 2024.2.6) 19 FEB 2024 12:41
The engine you are using is pdfTeX (from TeX Live
tried to typeset your file, context-test.tex, your computer
attempted to use pdftex rather than ConTeXt. To figure out why it did that, we
need to know how you are doing the typesetting. Do you use a command on the
command line? Are use using an editor that has a “typeset” button? Something
uitting
I wrote on Wednesday last week. I also did an download of cont- lmt and cont-
tmf. Don't know if there is a mistake which is my fault?
I don't know, maybe important:
The log file says:
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded
format=pdflatex 2024.2.6) 19 F
on. Rephrasing the question, can
> > LuaMetaTeX/ConTeXt compile
> > plain TeX files. If yes, how can I do that?
>
> You mix up two different things here.
>
> 1. Plain TeX is a collection of TeX macros like ConTeXt or LaTeX.
>
> 2. LuaMetaTeX is a program like pdfTeX or Lu
or LaTeX.
2. LuaMetaTeX is a program like pdfTeX or LuaTeX which provides commands
which are used by above mentioned collections to create macros.
Even though ConTeXt provides some commands which available in plain TeX
not all of the are supported which means you can't process plain TeX
documents
performance but
nevertheless luametatex became faster. It helps to develop on an older
machine and not on a yearly updated one as that obscures matters. (Not
that I'd not like a faster machine, but that comes at a steep price.)
Hans
ps. In the tranmsition from pdftex to luatex to luametatex
in engine.
One thing to keep in mind is that tex is an interpreter and all gets
tokenized which is more costly in a 32 bit engine than in an 8 bit one
(like pdftex). And although luametatex is more efficient than luatex
that gets offset by more features that come at a price, but we still
win
s abit special in te xdue to the fact thet some numbers
en dup in registers and others as token list (string). I have considered
changing that but it would also break some 'testing for tex version' so
for now we have to accept this mix of tex/etex/pdftex
quite wel now and refactoring is for me
counter productive. These are projects running for decades and engines
need to be stable so changes come slow.
You can compare the luanmetatex source to luatex and pdftex to see how
we proiceed.
Hans
LMTX generates more pages so it is
> > faster.
>
> puzzling
>
> > Of course, this is a meaningless experiment from a practical point of view
> > as a 1000 page document will be more complex than just text.
> % engine=pdftex 1.2
> % engine=luatmetatex 1.6
>
from a practical point of view as a
1000 page document will be more complex than just text.
% engine=pdftex 1.2
% engine=luatmetatex 1.6
% engine=luatex 1.8
% engine=xetex 2.4
\starttext
\dorecurse{500} {
\input knuth \par
}
\stoptext
125 pages, so how does your test file
ok in almost an instant using PDFTeX which is about 450+
> pages but my math book takes around 30 seconds averaging ~40 pages/second.
>
> Why LuaMetaTeX is so slow? How can I speed it up?
> --
> Re
On 1/18/2024 7:56 PM, Shiv Shankar Dayal wrote:
In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
lightning fast.
pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
comparison, try the TeXbook on LuaMetaTeX (I don’t know if “plain”
works
Hi,
On Thu, Jan 18, 2024 at 7:58 PM Shiv Shankar Dayal
wrote:
>
>
>
>
>> In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
>> lightning fast.
>>
>> pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
>> comparison, t
In comparison to LaTeX with LuaHBTeX, ConTeXt with LuaMetaTeX is
> lightning fast.
>
> pdfTeX is 8bit, and Knuth’s plain TeX is very low level – for a fairer
> comparison, try the TeXbook on LuaMetaTeX (I don’t know if “plain” works
> though).
>
I understand that why it is slo
Am 18.01.24 um 18:47 schrieb Pablo Rodriguez via ntg-context:
On 1/18/24 18:24, Shiv Shankar Dayal wrote:
I can process TeXBook in almost an instant using PDFTeX which is about
450+ pages but my math book takes around 30 seconds averaging ~40
pages/second.
Hi Shiv Shankar Dayal,
I guess
On 1/18/24 18:24, Shiv Shankar Dayal wrote:
> I can process TeXBook in almost an instant using PDFTeX which is about
> 450+ pages but my math book takes around 30 seconds averaging ~40
> pages/second.
Hi Shiv Shankar Dayal,
I guess that “The TeXbook” (having been written by Knuth him
I can process TeXBook in almost an instant using PDFTeX which is about 450+
pages but my math book takes around 30 seconds averaging ~40 pages/second.
Why LuaMetaTeX is so slow? How can I speed it up?
--
Respect,
Shiv Shankar Dayal
g useful. Nor
>> does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
>> work for me. Ocular starts, but always on the first page, regardless of
>> what line number I give it.
>> On the other hand, pdftex creates a .synctex file which my copy o
information
in it,
but I can't find any invocation of synctex to return anything useful.
Nor
does the okular example in the wiki
(https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other hand, pdftex
of synctex to return anything useful. Nor
does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other hand, pdftex creates a .synctex file which my copy of synctex
find
does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX)
work for me. Ocular starts, but always on the first page, regardless of
what line number I give it.
On the other hand, pdftex creates a .synctex file which my copy of synctex
find useful.
I am using the synctex from
in the distribution?
I'll check it but no time today.
btw ... as you like low level hacking ...
pdftex has a mechanism called pgc (pdf glyph containers) and these are
used when no pk font is found (which also means: no map entry)
\pdffont ... =
\pdfscale 1000
\pdfglyph 1 100 0 0 100 100
... pdf code
{ code = spec },
codepoint
)
fonts.constructors.addcharacters(
font.current(),
{ characters = { [codepoint] = spec } }
)
end
I specifically need something that writes out a raw PDF stream. I'm
using this to write a 4000+ page PDF file to be include
t; > $pdf_mode=1;
> I found back this link:
>
> https://davidcarlisle.github.io/latexcgi/testc
>
>
> % !TEX mtxrun --script context
>
> \starttext
>
> \dorecurse{500}{\samplefile{tufte}\par}
>
> \stoptext
>
> Runs 113 pages in 1.13 sec so
tufte}\par}
\stoptext
Runs 113 pages in 1.13 sec so quite ok for a remote un I guess.
I'm not sure how up to date it is.
(The default is some old tex document using pdftex.)
Hans
-
Hans Hage
frontend here; omega is dvi based
so like regular tex and etex whatever it does with fonts is not really
related to the engine bu tup to the backend: the engine only needs
metrics (omega extended tfm into ofm for that).
pdftex brought a pdf backend, xetex pipes into a dvi backend, luatex has
a pdf
ontinued quickly) and that its goal was solely within this input
processing spectrum. Because it wasn't.
Or heck
or heck. Let's go even further. By making the dubious assertion
that we've been built with noses to hold our eyeglasses lest these
eyeglasses fall off while reading, or that we'
part was mostly going beyond 8 bit fonts but i might have
missed something (omega was never productin ready).
It is xetex that hooked into opentype although pdftex can actually deal
with truetype fonts to some extend. Before there was something
'opentype' we had two competing but similar
with the trigonometric circle from the pgf manual,
quoted in https://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the mtx-install-modules.lua file
before doing mtxrun --script install-modules --install tikz
but I could guess that from a
ric circle from the pgf manual,
> > quoted in https://wiki.contextgarden.net/TikZ , does not compile
> > unless you also comment out
> > or find(n,"pdftex")
> > in line 181 of the mtx-install-modules.lua file
> > before doing mtxrun --script install-modu
cross works.
> >> The more complex example with the trigonometric circle from the pgf
> >> manual,
> >> quoted in https://wiki.contextgarden.net/TikZ , does not compile
> >> unless you also comment out
> >> or find(n,"pdftex")
> >> in lin
://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the mtx-install-modules.lua file
before doing mtxrun --script install-modules --install tikz
but I could guess that from a:
Driver file ``pgfsys-pdftex.def'' not found..
message
Ah so tikz
t; unless you also comment out
> or find(n,"pdftex")
> in line 181 of the mtx-install-modules.lua file
> before doing mtxrun --script install-modules --install tikz
> but I could guess that from a:
> Driver file ``pgfsys-pdftex.def'' not found..
> message
Ah so tikz uses b
Thanks a lot Aditya.
The very simple TikZ example with the cross works.
The more complex example with the trigonometric circle from the pgf manual,
quoted in https://wiki.contextgarden.net/TikZ , does not compile
unless you also comment out
or find(n,"pdftex")
in line 181 of the m
mtxrun --script install-modules --install --all
> >
> > doing exactly that?
> >
>
> Okay Floris. I see Aditya nearby. He'll take over from now on :) stand
> by please. I know you didn't ask the original question but this is over
> the pgfsys-pdftex and the
:) stand
by please. I know you didn't ask the original question but this is over
the pgfsys-pdftex and the pgfsys-luatex. It's a race between them !!
sort of
The solutions are a few if any really, either as I suggested first and update
afterwards or install tikz
if the driver is the problem, what does
\pgfsysdriver to an appropriate value
> before you load pgf.
> If you are going to use the dvips program, you set this macro to the value
> pgfsys-dvips.def;
> if you use pdftex or pdflatex, you set it to pgfsys-pdftex.def; and so on.
> In the following, details of the support of the d
s to luametatex is not
really putting a (performance) burden on this engine. In pdftex and
luatex it would have an impact, although in luatex somewhat less because
we prioritize our favourite units anyway.)
-
ndalone
> >
> > Now let's take a peek instide and see the binaries
> >
> > afm2tfm etex kpsereadlink mfmtxrun.lua texluac
> > bibtex extractbb kpsestat mf-nowin pdfetex tlmgr
> > context fmtutil
latexmkindex pdftex updmap
dvilualatex fmtutil-user luahbtex mktexfmt pktogf updmap-sys
dviluatexgftodvi lualatex mktexlsr pktype updmap-user
dvipdfm gftopkluametatex mktexmf rungs xdvi
dvipdfmx gftype
fmtxrun.lua texluac
bibtex extractbb kpsestat mf-nowin pdfetex tlmgr
context fmtutil kpsewhichmft pdflatex tlshell
context.lua fmtutil-sys latexmkindex pdftex updmap
dvilualatex fmtutil-user luahbtex mkte
> sources instead of inventing it (and when it comes to answering tex related
> questions chargpt is pretty unreliable, but that's another topic)
>
> > But instaed I looked at it and though to myself «how much has changed?!» In
> > plain TeX (I have forgotten it a bit) but I c
; \end
and it'll produce a dvi file in return.
a lot has changed: opentype math, unicode, more demands but indeed there
is nothing against using plain tex with cmr and dvi fonts if that suits
well; and plain tex will always be faster than context (or latex) just
like pdftex with 8 bit fonts is
> > \definefontsynonym[LucidaBrightDemiItalic][texnansi-lucidabrightdemiitalic][encoding=texnansi]
> >
> > \definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi]
> >
> > \definefontsynonym[LucidaBrightRegular][texnansi-lucidabr
nsi]
\definefontsynonym[LucidaBrightItalic][texnansi-lucidabrightitalic][encoding=texnansi]
\definefontsynonym[LucidaBrightRegular][texnansi-lucidabrightregular][encoding=texnansi]
\stoptypescript
these encodings only make sense with mkii (in which case the map file
tells pdf
g
through the ttf as it may be deprecated works. No doubt.
But look at the output of only a few lines.. This is exactly what I wanted to
see!:
system >6: filename=texnansi-bandh-lucida.map filetype=map
format=map
foundname=/usr/local/texlive/2023/texmf-local/fonts/map/pdftex/context
3/texmf-config,
home:texmf, !!selfautoparent:texmf-config, !!selfautoparent:texmf-var,
!!selfautoparent:texmf-project, !!selfautoparent:texmf-fonts,
!!selfautoparent:texmf-local, !!selfautoparent:texmf-dist}/fonts/enc/{dvips,
pdftex}//
resolvers | lists | res: .\{/home/ce/.texlive2023/texmf-co
/internal/telecom/
itdemos/internal/travel/
pdftex/
pragma/
present/euronts/
present/road/
present/talks/
present/tug-2000/
specials/fonts/
texdemos/suite/
sent 204 bytes received 17,573 bytes 11,851.33 bytes/sec
total size is 449,010,176 speedup is 25,257.93
/internal/telecom/
itdemos/internal/travel/
pdftex/
pragma/
present/euronts/
present/road/
present/talks/
present/tug-2000/
specials/fonts/
texdemos/suite/
sent 196 bytes received 13,933 bytes 28,258.00 bytes/sec
total size is 449,010,176 speedup is 31,779.33
aTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
Same here.
Any ideas what I should try to help debug this?
I was told that this is the default now, that isn't going to change,
and
that I could always use LuaTeX instead. I could also use LaTeX, I
guess, but I
re.
>>
>>> PDFs generated directly from Context MKIV from TeXLive 2022 using
>>> LuaTeX 1.5 render fine on these printers.
>>> I've also printed PDFs from pdfTeX in the past fine.
>> Same here.
>>
>>> Any ideas what I should try to help debug this?
>>
ld find.
Same here.
PDFs generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
Same here.
Any ideas what I should try to help debug this?
I was told that this is the default now, that i
IV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
Same here.
Any ideas what I should try to help debug this?
I was told that this is the default now, that isn't going to change, and
that I could always use LuaTeX instead. I
y page.
>> The PDFs render fine on every PDF reader I could find.
>> Conversion to PostScript with pstopdf (poppler-22.07.0) and then
>> sending the PS renders the document correctly on the printer.
>> PDFs generated directly from Context MKIV from TeXLive 2022 using
&g
ing the PS renders the document correctly on the printer.
PDFs generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
I attached the non-working 'foo.pdf.mkix'
and the working 'foo.pdf.mkiv' file
generated directly from Context MKIV from TeXLive 2022 using
LuaTeX 1.5 render fine on these printers.
I've also printed PDFs from pdfTeX in the past fine.
I attached the non-working 'foo.pdf.mkix'
and the working 'foo.pdf.mkiv' file.
I tried to disable font subsetting to debug this further, but
n file?
>
> Actually, we never had a greek hyphenation pattern file, only for
> ancient greek. Modern greek in mkii has not encoding defined (we're
> talking 2005 and before when Tomas made the greek encoding that dealt
> with utf in pdftex). It has to do with 'setting what are letters'
had a greek hyphenation pattern file, only for
ancient greek. Modern greek in mkii has not encoding defined (we're
talking 2005 and before when Tomas made the greek encoding that dealt
with utf in pdftex). It has to do with 'setting what are letters' and
these modern greek patterns have plenty
if LuaTeX is better than
pdfTeX/XeTeX, and some are complaining that LuaLaTeX is too slow, of
course...)
HR
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context
is definitely the correct approach.
That's what the rest of the TeX world already does (at least LuaTeX
and XeTeX; pdfTeX not of course), see
https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex
We have two sets of Cyrillic
oading both patterns at once is definitely the correct approach.
That's what the rest of the TeX world already does (at least LuaTeX
and XeTeX; pdfTeX not of course), see
https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/loadhyph/loadhyph-sr-latn.tex
We have two se
On 12/21/2021 10:50 AM, hanneder--- via ntg-context wrote:
I just started switching after long years of typesetting with
La-/Omega-/pdfTeX to Context and was exploring the capabilities of the
program for typesetting critical editions. So I was
wondering whether there is any updated
aff.uni-marburg.de
> Betreff: [NTG-context] Critical Editions?
>
>
> I just started switching after long years of typesetting with La-/Omega-
> /pdfTeX to Context and was exploring the capabilities of the program for
> typesetting critical editions. So I was wondering whether there
I just started switching after long years of typesetting with
La-/Omega-/pdfTeX to Context and was exploring the capabilities of the
program for typesetting critical editions. So I was
wondering whether there is any updated information on how to produce
critical editions?
Details:
I
: the local box width
> \localboxoffset: the total distance to the edge
> \localboxleftskip : the effective leftskip
> \localboxrightskip : the effective rightskip
> \localboxlefthang : the current shape related value
> \localboxrighthang :
to normalized lines and as such there is plenty to
play with. Others can be seen in the examples.
I might add some more control to both these 'injection' mechanism
because directly out of the (pdftex/omega/luatex) they are not that
useful (which is probably also why we don't use them
/perl5/bin:.:/Applications/Qt/current/clang_64/bin:/usr/X11/bin
dvipdfmx: /opt/local/bin/dvipdfmx
dvips: /opt/local/bin/dvips
fmtutil: /opt/local/bin/fmtutil
kpsewhich: /opt/local/bin/kpsewhich
luatex:/opt/local/bin/luatex
mktexpk: /opt/local/bin/mktexpk
pdf
\skip0=10pt plus 10pt minus 10pt plus 20pt
test \skip0=10pt plus 10pt plus 20pt minus 10pt
test \vrule width 10pt height 10pt depth 10pt depth 10pt height 10pt
% test \hbox to 10pt to 10pt {x}
\stoptext
compare pdftex and luametatex.
ok. but why does this run fine
\starttext
Test
>>> values?
>> I think the only examples are in mails from Hans. When you set multiple plus
>> or minus values (as far as i remember) only the last setting is used and all
>> previous ones are ignored.
> Maybe in some article. Anyway, here is an example:
>
> \starttex
10pt
test \vrule width 10pt height 10pt depth 10pt depth 10pt height 10pt
% test \hbox to 10pt to 10pt {x}
\stoptext
compare pdftex and luametatex.
Hans
-
Hans Hagen | PRAGMA ADE
the are implemented and the way
TeX (the engine) works when it reads arguments.
and, also in mkiv \dofmode is unexpandable so cannot act as keyword
(it might not crash but also doesn't work)
Here is a short example which demonstrates the differences between
LuaTeX (eTeX, pdfTeX etc.) and LuaMetaTeX
early in
\MKII\ we had a positioning mechanism available. At that time we had
\DVI\ output and specials were used to track positions. A script
calculated the positions that were then fed back into the second run.
Later Taco wrote \DVIPOS\ which sped up the analysis between runs. When
\PDFTEX
:texmf",
-- We need texmfos for a few rare files but as I have a few more
bin trees
-- a hack is needed. Maybe other users also have texmf-platform-new
trees.
TEXMF =
"{$TEXMFCONFIG,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFPROJE
implemented in pdftex and xetex.
Two TeX January 2021 DEK buglet fixes (H.Hagen)
Mark math glyphs as protected (in order to prevent processing
as text in base mode).
Removed width/ic compensation for traditional math code path.
When restricted system commands is enabled os.setenv has no effect
Hi,
The 2021 texlive code is currently being frozen. This means that Mojca
will check-in the current context release right before tl gets deep frozen.
The MKII code (mkii and mpii files) hasn't changed so it should still
work well with pdftex and xetex although I admit that I haven't checked
tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
fullname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
usedmethod=database
system > 11: filename=lmmono12-regular filetype=otf format=otf
foundname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm/
w method (more lmtx-ish)
(actually with mkii in pdftex we need .3 seconds, xetex freezes with
100K but needs 0.53 for 10K, luatex needs 0.18)
but I'm sure you don't care much about that so I just implements a
variant with warning which takes .19 seconds per 100K so it's a nice
compromise. (Prob
some prefixes that we never used in
context anyway), some etex enhancements brought new primitives (some
make no sense in the luametex universe but one can always fake
something), some auxiliary pdftex primitives never were available in
lua(meta)tex because we have lua, and from omega/aleph we
it seems it's there.
depends on what you consider (non) hdpi ... the positioning of glyphs
depends on font scale, rounding of stems and such (hints in fonts but
these get less relevant with high res displays), caching, inter glyph
corrections (that pdftex/luatex/...) put in the text stream
well? Because it seems it's there.
>
> depends on what you consider (non) hdpi ... the positioning of glyphs
> depends on font scale, rounding of stems and such (hints in fonts but
> these get less relevant with high res displays), caching, inter glyph
> corrections (that pdftex/luatex/...)
of glyphs
depends on font scale, rounding of stems and such (hints in fonts but
these get less relevant with high res displays), caching, inter glyph
corrections (that pdftex/luatex/...) put in the text stream to resync
within certain tolerances, etc ... (often a print is a better reference
the meantime we got etex extensions, which
adds a few more, and then pdftex ades some, as well as omega and after
that of course luatex. In luametatex we dropped some, and added others,
so there we currently have 770 primitives. The increase of number is
partly due to the 166 extra math related
apply to \vskip, wouldn’t it?
also for \hrule and \vrule (and in pdftex/luatex some backend related
primitives); primitives like \hbox have their keyword scan terminated by
a leftbrace token
Hans
and one can be pretty sure that we then
don't have a proper csname. This is why in luatex we have a catch for
running wild csname checking.
The original \ifcsname test was inherited from etex. The \protected
feature also comes from etex. But \csname is a tex natural.
In pdftex (and luatex
then don't have a proper
csname. This is why in luatex we have a catch for running wild csname
checking.
The original \ifcsname test was inherited from etex. The \protected
feature also comes from etex. But \csname is a tex natural.
In pdftex (and luatex) a protected macro inside an \(if)csname does
parameters and dimensions
are involved in that).
Actually, in luatex slanting and expanding (which is also kind of
bondeling) have been inherited from pdftex. Boldening text is one case,
but dealing with math yet another and the luatex engine only has some
additional font property (linewidth
t;
The same thing occurs while context is as a file at the very root on
c:\, or within c:\windows, or in C:\Users\adeim\Documents\context>
I suggest to use the installer from Hans website when you don't need
pdfTeX.
http://www.pragma-ade.nl/insta
t;
The same thing occurs while context is as a file at the very root on
c:\, or within c:\windows, or in C:\Users\adeim\Documents\context>
I suggest to use the installer from Hans website when you don't need pdfTeX.
http://www.pragma-ade.nl/insta
od=database
system > 10: filename=latinmodern-math.otf filetype=opentypefonts
foundname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
fullname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
usedmethod=database
system
ename=knuth filetype=tex
foundname=d:/Ctx-Beta/tex/texmf-context/tex/context/sample/common/knuth.tex
fullname=d:/Ctx-Beta/tex/texmf-context/tex/context/sample/common/knuth.tex
usedmethod=database
system > 12: filename=pdftex.map filetype=map format=map
foundname=d:/Ctx-Beta/tex/t
> 10: filename=latinmodern-math.otf filetype=opentypefonts
foundname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
fullname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm-math/latinmodern-math.otf
usedmethod=database
system > 11: filename=pdftex.map fi
/tex/texmf/fonts/opentype/public/lm/lmroman12-regular.otf
fullname=d:/Ctx-Beta/tex/texmf/fonts/opentype/public/lm/lmroman12-regular.otf
usedmethod=database
system > 10: filename=latinmodern-math.otf filetype=opentypefonts
foundname=d:/Ctx-Beta/tex/texmf/fonts/opentype/publ
nment.oldhome or "??")
\stopluacode
\stoptext
ChkEnv.pdf
Description: Adobe PDF document
-- generator : luat-sta.lua
-- state tag : whatever
return {
["context"]={
["version"]="beta",
},
["engines"]={
["luatex"]=true,
[&quo
ges/second
Ok, that is not bad (I think on my already old machine one run took some
18 seconds for luatex and of course in mkii with pdftex I could watch a
movie while processing the file.)
The memory footprint also looks ok, especially given all these graphics.
(in most cases lmtx
ngine=luatex" at the
top line of the source file (but no pdftex and xetex in this installer).
FWIW, the lmtx installation ships with the latest experimental luatex
binary but normally that should not have consequences, but it does
permits testing occasional updates.
Hans
The binary f
e
> the engine in the usual way with "% engine=luatex" at the top line of the
> source file (but no pdftex and xetex in this installer).
I updated LMTX on MacOSX 10.13 today.
The luatex binary in not executable, thus when I run
axel$ context --luatex --version
mtx-context
1 - 100 of 3678 matches
Mail list logo
